The real-time rendering of three-dimensional graphics has a number of appealing applications on mobile terminals, including games, man-machine interfaces, messaging and m-commerce. Since three-dimensional rendering is a computationally expensive task, dedicated hardware must often be built to reach sufficient performance. Innovative ways of lowering the complexity and bandwidth usage of this hardware architecture are thus of great importance.
The main bottleneck, especially for mobile phones, is memory bandwidth. A common technique for reducing memory bandwidth usage is texture compression. Texturing refers to the process of “gluing” images (here called textures) onto the rendered triangles. If the textures are compressed in memory, and then during accessing they are decompressed, a significant amount of bandwidth usage can be avoided.
Most texture compression schemes are concentrating on image-type data, such as photographs. However, with the advent of programmable shaders, textures have started to be used for many other types of data than just traditional photographic images. Bump mapping has therefore become a widespread technique which adds the illusion of detail to geometrical objects in an inexpensive way. More specifically, a texture, called a bump map or normal map, is used at each pixel to perturb the surface normal. A common approach to generate normal maps is to start with a high polygon count model and create a low complexity model using some geometrical simplification algorithm. The “difference” between these two models is then “baked” into a normal map. For real-time rendering, the normal map is applied to the low complexity model, giving it a more detailed appearance. For instance, the document [1] shows how it is possible to go from a very high triangle-count model (15 000 polygons) to a very low one (1 000 polygons) with preserved quality by using normal maps.
To be able to use lower polygon-count models is of course very attractive for mobile devices and terminals, since they have lower computational performance than PC systems.
In the majority of cases today, bump mapping is performed in local tangent space (X, Y, Z), of each rendering primitive, e.g. a triangle. Since the length of the normal is not of interest, unit normals can be employed. Thus, the problem is to compress triplets (X, Y, Z), where X2+Y2+Z2=1. The simplest scheme, is just to treat X, Y, Z as RGB (Red, Green, Blue) and compress it with S3TC/DXT1 [2], but that gives rather bad quality.
Actually, for smooth surfaces it turns out that even uncompressed RGB888/XYZ888 does not give enough quality for some objects. Especially for smooth surfaces, more than eight bits are needed. Therefore ATI Technologies developed 3Dc [1], which is a compression format that will often allow higher quality than XYZ888.
In 3Dc only X and Y are compressed, and Z is calculated using equation 1:Z=√{square root over (1−X2−Y2)}  (1)
X and Y are compressed separately. The X-values are grouped into blocks of 4×4 pixels. These values can range from −127.000 to +127.000, (or alternatively, from 0 to 255), but they are often clustered in an interval. 3Dc takes advantage of this and specifies this value using 16 bits: eight bits for the start of the interval and eight bits for the end of the interval.
Inside this interval, each value is specified using 3 bits each. This means that eight reconstruction levels within the interval are possible. The reconstruction levels are always equispaced (evenly spaced) in the X-direction and equispaced in the Y-direction. However, the distance between such reconstruction level in X-direction is, though, typically different from the corresponding distance in the Y-direction. This usage of a grid of reconstruction levels having different resolutions in the two perpendicular directions/axis is though not always a good representations of the original normals of blocks to be compressed.